In computer science, a virtual machine (VM) is a portion of software that, when executed on appropriate hardware, creates an environment allowing the virtualization of an actual physical computer system. Each VM may function as a self-contained platform, running its own operating system (OS) and software applications (processes). Typically, a virtual machine monitor (VMM) or hypervisor manages allocation and virtualization of computer resources and performs context switching, as may be necessary, to cycle between various VMs.
Frequently, a guest running on a virtual machine should be migrated from a current hypervisor (i.e., the source hypervisor) to a different hypervisor (i.e., the destination hypervisor). For example, a virtual machine that is centrally hosted may require live migration or migration to a file for a variety of reasons, including load balancing on the host server, maintenance of the host server, upgrades of software and/or hardware of the host server, and so on. To perform the migration, the state of the guest executing on the source hypervisor should be realized and restored on the destination hypervisor.
Typically, to properly restore the state of the virtual machine during migration, the destination hypervisor is set up to be substantially identical to the source hypervisor. If the two hypervisors are configured in substantially the same way, then the state information of the virtual machine serialized by the source hypervisor may be loaded by destination hypervisor. However, this is problematic from a support perspective because advance knowledge of the migration and mirroring of the specific configurations of the source and destination hypervisors may not be possible.
This approach may be particularly problematic in cases where migration is desired from a new version of the hypervisor running on the source hypervisor to an old version of the hypervisor running on the destination hypervisor. Frequently, the new version of the hypervisor has been updated, modified, and or changed in order to support new functionality that is not supported by the old version. In such cases, when there is an attempted migration from the source hypervisor (running the new version) to the destination hypervisor (running the old version), the state information for the new functionality supported by the new version may be serialized by the source hypervisor, however, the old version running on the destination hypervisor may not expect the serialized state (since the functionality is not present in the old version), causing migration to fail.
In addition, bugs or problems may be detected in an old version of the hypervisor which are fixed in a new version of the hypervisor. However, this causes a disconnect during migration from the old version of the hypervisor (with the bug) to the new version of the hypervisor (without the bug) when restoring the state information of the virtual machine on the destination hypervisor. Specifically, when the old version migrates to a new version, it may include a corrupted state. For example, the old version may include a bug in a specific register supported by a CPU. When a guest reads that corrupted register, the guest receives incorrect values for the CPU and the guest crashes, while in a specific state. If migration were to occur, the specific state of the guest following the crash would be migrated to the new version of the hypervisor. As such, even if the new version fixed the register bug, the new version would receive the migrated state (i.e., the corrupted state) of the old version.